Shopping List Management on Mobile Phones

 

 

Weight: 40%

 

Deadline: Thursday 31 March at 16:00

 

This is an individual programming exercise. The aim of the exercise is to develop a program for managing shopping lists on mobile phones.

 

The program will be developed in a number of stages, starting with a basic configuration which is enhanced by the introduction of additional features in a series of stages. In developing your program it is essential that you first ensure that the basic configuration is fully functional before you move on to the introduction of the additional features.

 

Core Functionality

 

Basic Configuration

 

The basic configuration manages a single shopping list. The program allows users to create a new shopping list by typing in a set of shopping list items. The shopping list may contain any number of items, while for each item it contains the name and the quantity to be purchased. The program persistently stores the created shopping list. The program also allows users to load the created shopping list when out shopping, and to mark each product they buy as purchased in the list.

 

Tracking Weekly Shopping

 

This configuration manages a number of shopping lists, one for shopping trip. The program allows users to create a new shopping list for a shopping trip, either by typing in the set of items, as in the basic configuration, or loading and configuring any of the previously created shopping lists. In the latter case the user can configure a shopping list by adding new items to it, removing some of the existing items, or editing the quantity of a particular item to be purchased. Every created shopping list is persistently stored and associated with a name and the date it was created.

 

Tracking Shopping Cost

 

This configuration adds to either of the above two configurations the ability to record prices for purchased products and to track the current total of all purchased products. For this purpose the program should allow users to load a previously created shopping list and while shopping enter the price and quantity of each purchased item. As items are purchased the application calculates and constantly displays the total price of all items purchased so far. The application also persistently stores all items purchased, their prices, and the total price.

 

Sharing Shopping Lists

 

This configuration adds to either of the above three configurations the ability to exchange over Bluetooth shopping lists between mobile phones. The application should allow users to search for Bluetooth enabled devices that support the application and to choose which device to use for shopping list exchange from the list of detected ones. When a device is chosen, then the application allows the user to push a previously created shopping list to the chosen device. The chosen device has the option to either accept or reject the pushed list. If a pushed list is accepted, then the device has the option of either storing it as a newly created one or to merge it with a previously created shopping list. In the latter case, a new merged list replaces the original one, and includes all items from both lists (union of items) and for any items shared by both lists the aggregate quantity.

 

Enhanced Functionality

 

This configuration adds a number of enhanced features to a program that offers all the features of the above four configurations (i.e. you should only attempt this part after you can completed all the earlier ones). The list of enhanced features includes:

  1. Auto-removal of purchased items. This feature supports the user when shopping by automatically removing from the shopping list any item that has been purchased. As a result, the list is gradually reduced in size until it potentially becomes empty. The auto-removal of purchased items should not interfere with the persistent storage of information, i.e. is only limited to the interface of the application.
  2. Shopping memory. This feature supports the user both when creating a shopping list and when shopping. When the user is creating a new shopping list, the program compares the last shopping list that the user created against the last list of purchases and if there are any items that were not purchased at all or were purchased but in quantities that were smaller than what was indicated in the shopping list, it adds automatically these items to the new shopping list with the appropriate quantities. The user can of course edit the automatically created list to remove items and adjust their quantities.
  3. Price comparison. When shopping, whenever the user enters the price of a purchased item the program checks the last list of purchases and if the same item is included it compares the current price to the old one and indicates whether it is higher or lower. Note that if feature a. above is also implemented the user must be given some time to notice this information before the item is removed from the current shopping list.
  4. List interoperability. To enhance the interoperability of exchanged lists, lists are converted into XML before exchange. Each list comprises of a name (string) and a list of items, where each item comprises of a name (string) and a price (real number). Note that this enhancement should not really affect the way lists are stored, i.e. conversion to XML just before exchange, while received lists are converted before they are stored.

 

Marking scheme

 

The exercise is marked out of 100 marks. Note that any marks earned beyond 100 will not be lost!

 

Each configuration is given the marks listed below:

 

The enhanced features are given marks only if at least three of the earlier configurations have been attempted. Each enhanced feature is given the marks listed below:

 

An additional 10 marks are given if all the implemented features are demonstrated on a mobile phone. In order to demonstrate list exchange it is a good idea to pair up with one of your classmates.

 

The exercise is marked on the range of supported features and configurations, the extent to which these are fully functional and satisfy the requirements specified above.

 

Submission & Demonstration

 

You must submit the exercise on Spider before the deadline. You submission must be a single ZIP file that includes:

  1. A brief report (no more than 2 pages) describing your implementation and clearly identifying which particular configurations and features your implementation supports. The report must also have a cover page with your name, registration number and the signed statement “Except where explicitly stated, this report is my own work”.
  2. All the Java source code files of your program.

 

As part of the marking of the exercise, in addition to the submission you must also demonstrate your code in the lab. The demonstrations will take place at the usual lab time and place for the class on a schedule that would be set closer to the deadline. Note that submissions that are not demonstrated will not be marked!